Gitlab CI|CD
我们项目的部署方式为每当合并 MR 时, 在我们的一台测试机器上监听并处理收到的 webhook 请求，在机器上有我们的项目文件夹，收到请求后，在项目文件夹内切换分支，拉取最新代码，并进行 build, 之后部署到 apache 服务器。
这样的部署有几个不好的地方:
- 需要在云服务器开通一个端口监听 webhook
- 当依赖发生变更时需要手动登录到机器重新 install 依赖，或者需要添加代码判断 package.json 是否有变化，有变化再重新安装依赖
- 维护比较困难，如果来了新的同事，想要优化下部署代码需要重新阅读之前的实现代码
为了使得部署更加方便，我之前也做过一点优化，如在连接公司的 gitlab 失败后自动更换 VPN 账户密码等。
最近试了下 gitlab 的 ci/cd 功能，发现还是非常好用的。要使用这个功能，一个很重要的配置文件就是 gitlab-ci.yml 文件
接单介绍下 gitlab-ci.yml 的几个概念。
每一次的构建过程称为一次 pipeline。 每个 pipeline 又包含很多 stage，stage 是串行执行的。每个 stage 又包含若干个 job，job 之前是并行执行的，stage 内的每个 job 执行完后进入下个 stage。
首先要编写 gitlab-ci.yml 文件（默认放在根目录），比较重要的配置项是 script, 在这里面写我们的处理脚本，在我们使用 cd 等命令时，默认目录是相对于我们的项目根目录下（gitlab-ci.yml文件所在目录）。还需要使用 only 指定分支，只在当前分支 push 时执行 job。
我写了三个 stage: install_depencies、build、deploy
install_depencies 时每次都会重新安装依赖，解决了之前我们的部署依赖更新需要手动安装的问题，然后可以把依赖进行 cache, 通过 key 控制 cache 的策略。减少任务执行时间。
然后需要一个 runner 来执行我们的配置。于是我在测试机器（ubuntu）上注册了 gitlab-runner
1 | gitlab-runner register |
这个命令最后会选择 excutor， 我选择了个比较简单的 shell，因为之前我们的部署基本也都是 shell 命令，可以拿来复用。执行完后创建了一个 gitlab-runner 用户，为了防止报权限类的错误，我修改了 /etc/passwd 文件， 将这个用户赋予了 root 权限。然后还会发现 /home/gitlab-runner/ 下多了几个文件夹， 其中包含一个项目文件夹。我们的所写的 script 下的脚本都是在这个项目目录下执行的。